Nous allons vous apprendre dans ce cours des techniques pour Analyser et Concevoir des Systèmes d'Information…
Nous nous servirons du parallèle avec la réalisation d’une oeuvre d’architecte (comme une maison, cf. [Architecte]).
|
|
uniquement une aide à vos notes personnelles |
Comme tout le reste du programme enseigné au DUT, ce cours est une adaptation du PPN :
Le module ACSI se décompose en deux parties principales (Unités de Formation) :
|
|
Ces éléments sont tirés du PPN. |
|
|
Ces éléments sont tirés du PPN. |
|
|
Voici un exemple :
|
|
|
Rien ne vaut la pratique elle-même! |
Plan de cette partie :
Note: Dans nos enseignements de DUT Informatique, cette partie est abordée en 3ème semestre.
Ce qu’on peut dire de Merise :
On complète Descartes :
Intersection entre vues et niveaux
| Flux | Traitements | Données | |
|---|---|---|---|
Conceptuel |
|||
Organisationel |
|||
Logique |
|||
Technique |
Démarche par étape
|
|
On verra ça plus tard |
Ces flux ne nous intéressent pas car ils ne concernent pas le domaine à informatiser.
|
|
Dans de rares cas, on représentera tout de même les flux entre certains acteurs externes pour une meilleure compréhension du système. |
La représentation doit donner lieu à 2 flux distincts.
| Flux | Traitements | Données | |
|---|---|---|---|
Conceptuel |
MCF |
||
Organisationel |
|||
Logique |
|||
Technique |
| Flux | Traitements | Données | |
|---|---|---|---|
Conceptuel |
MCF |
||
Organisationel |
MOF |
||
Logique |
|||
Technique |
|
|
MCF 1. Demande CB 2. Refus 3. Demande Groupée CB 4. Livraison CB 5. Avis de mise à disposition et avis de prél. 6. Retrait de la carte |
|
|
MOF 1. Demande CB 2. Refus 3. Demande Groupée CB 4. Livraison CB 5. Avis de mise à disposition et avis de prél. 6. Retrait de la carte |
Répondre au QUOI?
Répondre au QUI fait QUOI et QUAND?
| Flux | Traitements | Données | |
|---|---|---|---|
Conceptuel |
MCT |
||
Organisationel |
MOT |
||
Logique |
|||
Technique |
| Flux | Traitements | Données | |
|---|---|---|---|
Conceptuel |
MCT |
||
Organisationel |
MOT |
||
Logique |
|||
Technique |
Arrivée d’une cde, dde du client…
18h, tous les lundis matin…
résultat d’une opération précédente
Opérateurs :
|
|
|
création, lecture, modification, suppression
impression, …
résultat de l’action
1 ou plusieurs
|
|
|
|
|
Une opération possède au moins un événement résultat par règle d'émission. Un résultat externe est toujours dirigé vers un acteur externe ou un autre domaine. |
| Flux | Traitements | Données | |
|---|---|---|---|
Conceptuel |
MCT |
||
Organisationel |
MOT |
||
Logique |
|||
Technique |
|
|
Certaines combinaisons plus fréquentes
|
|
|
Certaines implications
|
|
|
Possibilité de compléter les informations
|
Représentation d’un échange d’informations entre deux acteurs du domaine étudié ex: livraison, paiement
Pourquoi a-t’on décidé de "zapper" ces niveaux…
Le SI n’est qu’une composante du Système Organisationnel.
Le but de ce cours :
Une organisation est un ensemble d’objets structurés hiérarchiquement et fonctionnellement par un ensemble d’associations et ayant des buts définis.
Objets possible :
Une association est une relation existant entre deux ou plusieurs objets
Exemples d’associations :
|
|
Exemples d’organisations
une entreprise, une université, un IUT, une administration, une association 1901, … |
L’environnement d’une organisation est constitué par un ensemble d’objets externes à l’organisation et en relation directe avec elle.
Exemples pour une entreprise :
Question : quel est l’environnement de l’IUT? Et de l’université elle-même?
Exemples pour l’UTM :
Exemples pour l’IUT :
Un système organisationnel (SO) est constitué par une organisation, son environnement et l’ensemble des associations qui lient les objets de l’organisation et de l’environnement.
La structure d’un SO est constituée par l’ensemble des éléments (objets et associations) qui le composent.
Chaque élément est décrit par un ensemble de propriétés structurelles.
La structure d’un SO peut changer au cours du temps par :
Une organisation interagit de façon permanente avec son environnement de façon à maintenir une situation d’équilibre.
Un événement d’activité est un fait élémentaire du flux d’activité opérationnelle.
Des perturbations externes ou internes du flux d’activité opérationnelle entraînent des ruptures d’équilibre.
On désignera par activité de gestion l’ensemble des moyens et des méthodes permettant de contrôler l’activité opérationnelle de façon à conserver ou rétablir un état d’équilibre lors de perturbations.
Un SO est composé de deux sous-systèmes :
Le système de pilotage (ou de décision) fixe les objectifs, contrôle leur réalisation et apporte les modifications nécessaires.
Le système d’information est un ensemble organisé de ressources (personnel, données, méthodes, matériel, logiciel,…) permettant d’acquérir, de stocker, de traiter et de communiquer des informations dans des organisations. Le SI permet la coordination des activités de l’organisation et lui permet ainsi d’atteindre ses objectifs.
Le système opérant fabrique les produits et transforme les matières premières.
Toute prise de décision s’effectue en trois temps :
La classification des décisions peut se faire de deux façons :
Le niveau d’une décision est l’impact de l’action dans l’activité de l’organisation.
Exemples :
Manière de procéder pour identifier le phénomène et/ou pour résoudre le problème.
Connaissance de toutes les conditions et de la méthode de résolution utilisée (algorithme)
Existence d’un modèle (mathématique, RO, statistique, comptable, économique…)
Aucune méthode, aucun modèle (intuition, expérience)
Le système d’information est un ensemble organisé de ressources permettant d’acquérir, de stocker, de traiter et de communiquer des informations dans des organisations
Ces éléments seront modélisés grâce à UML.
Plan de cette partie :
Les trois types de programmes :
Les types d’IHM :
Il n’existe pas de modèle de description d’IHM en UML ou en Merise. Nous allons donc voir le SNI de la méthode MACAO.
Le SNI permet de concevoir et de modéliser la logique d’enchaînement des fonctions de l’application en fonction du comportement supposé de l’utilisateur.
Le SNI est purement conceptuel :
Le SNI concerne de la partie "Vue" du MVC.
On appellera "Unité de Dialogue" (UD) l’ensemble des fonctions offertes à l’utilisateur de façon simultanée (sur un même écran, dans une même fenêtre, dans une même page).
Chaque UD est représentée par un ou plusieurs symboles dans le SNI.
|
|
Une UD élémentaire = un seul symbole |
Deux modes de construction
|
|
Règles des retours implicites
Après une UDE, le retour implicite s’effectue sur l’UD précédente. Après une option d’un menu juxtaposé à une UD (élémentaire ou composée) le retour implicite s’effectue sur l’UD juxtaposée. |
|
|
Filtres associés aux listes
Permet de restreindre le nombre de lignes d’une liste. |
|
|
Tris multiples des listes
Permet de trier une liste de différentes façons. |
|
|
Rôles et conditions d’accès
Les rôles et les conditions d’accès permettent de contraindre les accès aux menus
( |
Au cours de l’acquisition des exigences ou
En rétro-conception d’IHM :
Le SNI obtenu représente alors le squelette du SNI final.
Les exigences :
Complément 1 : Nouveaux étudiants et Constitution groupes
Complément 2 : Gestion complète des groupes
Complément 3 : Saisie des notes d’un partiel
Cinq patrons d’IHM obtenus à partir du diagramme des classes
*)
Cette partie, réalisée en 1ère année de DUT en 2011/2012, n’est pas encore intégrée à ce support. Elle est proche du [SEP].
Ni Merise ni UML n’ont de schémas spécifiques pour représenter les interfaces graphiques, ni les enchaînements des pages dans un site web par exemple. On peut par exemple utiliser un diagramme d'état UML où chaque état est une page et les transitions représentent les événements qui font passer d’une page à l’autre.
La méthode MACAO, déjà évoquée introduit plusieurs schémas utiles à cet effet, que nous allons reprendre dans ce cours. Le livre de Pascal Roques [Roques2007a] reprend par exemple ce genre de diagramme dans sa démarche globale de conception de site web.
Le SEP (Schéma d’Enchaînement des Pages) que nous voyons ici complète le SNI vu précédemment (cf. SNI).
On peut distinguer 4 types de pages :
Un cadre est un découpage rectangulaire pouvant accueillir une page HTML (y compris une autre page de cadres).
Une page de cadre est divisée en deux ou plusieurs cadres occupant la totalité de la page.
Pages ne contenant que des objets visuels constants statiques et des objets de navigation :
|
|
Pages rencontrées habituellement en surfant sur le Net. |
Analogues aux précédentes mais comportant en plus des données variables obtenues par calcul ou lues dans des fichiers ou des bases de données.
Méthodes d’obtention :
Pages contenant des objets de saisie (équivalentes aux boîtes de dialogue de saisie)
Une page peut contenir 3 catégories d’objets :
Ils permettent d’indiquer les zones d’interaction avec l’utilisateur.
On trouve :
<TR>, <TD>, divisions de pages <DIV>…
Ils ne sont utilisés que pour les affichages statiques et n’ont pas besoin d'être identifiés de façon précise.
On trouve :
Ils permettent d’assurer les interactions utilisateur : actions, saisie, navigation
On trouve :
Cette partie fait l’objet dans le cours de DUT d’une intervention particulière, par une professionnelle de l'érgonomie. Nous reprenons simplement ici quelques grands principes.
Utilisez des divisions pour placer les informations répétées sur plusieurs pages : menus, en-têtes…
Utilisez des tableaux plutôt que des listes déroulantes
Les règles de structuration des boîtes de dialogue sont applicables la plupart du temps (alignement des champs affichés, regroupement des contrôles par famille, …)
Effectuez les « contrôles de surface » en local (fonction javascript par exemple)
Utilisez des polices standard (Arial, Times, Verdana)
Utilisez plutôt des fonds de pages clairs et une écriture sombre
Utilisez des feuilles de styles (CSS) pour les polices et les balises de présentations de textes : <A>, <H1>…
Caractéristiques générales :
Un certain nombre d’outils existent pour faire des dessins complexes. Le prototypage rapide d’interface graphique est important pour valider au plus tôt les besoins du client (au moins en terme d’interface).
Nous n’en donnons que quelques-uns ici.
Dans cette partie, nous allons aborder une démarche générale de conception. Nous allons aborder des diagrammes UML comme le diagramme des cas d’utilisation ou de séquences. Dans nos enseignements de DUT Informatique, cette partie est abordée en 3ème semestre.
n’est donné ici qu'à titre d’exemple. Aucune démarche n’est associée à UML et nous faisons une agrégation ici des meilleures pratiques entre UML et Merise.
Pour continuer avec l’image de l’architecte, il s’agit pour lui de s’assurer, par une démarche systématique, du succès de son projet.
Plan de cette partie :
Le Diagramme des Cas d’Utilisation est un modèle UML permettant de représenter :
|
|
On notera simplement |
Un cas d’utilisation représente un ensemble de scénarios que le système doit exécuter pour produire un résultat observable par un acteur.
Retrait par carte bancaire
L’UC démarre lorsque le Guichet Automatique Bancaire (GAB) demande au client son numéro confidentiel après l’introduction de sa CB. Le client entre son code et valide son entrée. Le GAB contrôle la validité du code. Si le code est valide, le GAB autorise le retrait et l’UC se termine.
Le client peut à tout instant annuler l’opération. La carte est éjectée et l’UC se termine.
UC01 ou RetraitCB (pour Retrait par carte bleue)
Un cas d’utilisation peut être précisé par :
|
|
Dans les outils, cette "précision" se manifeste par le fait que l’on "attache"
généralement un diagramme de séquence à un cas d’utilisation (clic droit sur un UC → nouveau |
Un acteur peut être une personne, un ensemble de personnes, un logiciel, un processus qui interagit avec un ou plusieurs UC.
On peut trouver plusieurs types d’acteurs :
actor Diagramme d’UC ci-après)
<<metaclass>>
<<utility>>
<<process>>
<<thread>>
<<powertype>>
<<extend>>)
Indique que l’UC source est éventuellement exécutée en complément de l’UC destination (cas particulier, erreur…)
<<include>>)
Indique qu’un UC est inclus obligatoirement dans un autre UC (notion de sous-programme par exemple)
Relation entre un UC général et un autre plus spécialisé qui hérite de ses caractéristiques et en rajoute
|
|
On n’utilise généralement |
Deux cas peuvent se présenter :
Chaque tâche informatique du nouveau MOT devient un UC
Les cas d’utilisation doivent directement être extraits des interviews d’utilisateurs ou des compte-rendus de réunions (cf. cas général ci-dessus).
Un ensemble d’opérations définit le comportement de l’objet (ex : setVitesse(valeur)),
c’est à dire son interface.
|
|
Rappel : chaque opération a un argument implicite qui est l’objet sur lequel elle porte. Exemple : |
Un accesseur getX() permet de consulter l’attribut X de l’objet, le modificateur setX(val) permet de modifier la valeur de l’attribut X avec le paramètre val. Par défaut, on doit avoir un accesseur par attribut privé.
Il existe 4 niveaux de visibilité des attributs et des opérations :
- privé (l’élément n’est visible que par la classe)
+ public (l’élément est visible par toutes les autres classes)
# protégé (l’élément est visible par la classe et ses sous-classes)
~ package (l’élément est visible par la classe et les classes du même paquetage)
Les paquetages permettent de regrouper les éléments de modélisation. Ils peuvent contenir d’autres sous-paquetages sans limites de niveaux.
Le paquetage est un espace de nommage.
Un paquetage peut importer une classe issue d’un autre paquetage.
Exemple : Vehicules::Voitures signifie que la classe Voiture est importée du paquetage Vehicules.
|
|
On emploiera souvent dans ce cours le terme anglais de package pour désigner un paquetage. |
Voici quelques exemples de diagramme de classes et du code java associé.
Catalogue du package Cataloguepackage Catalogue; import java.util.Date; public class Catalogue { private String nom; private Date dateCreation; public Catalogue() { ... } public Livre chercherLivre(String isbn) { ... } }
Adherent hérite de Personnepublic abstract class Personne { private String nom; private String prenom; protected Date dateNaissance; private static int ageMajorite = 18; public abstract int calculerDureePret() {... } public static void setAgeMajorite (int aMaj) {... } } public class Adherent extends Personne { private int iD; public Adherent() { ... } public int getAge() { ... } public int calculerDureePret() { ... } }
public class A1 { private B1 leB1; } public class A2 { private B2 lesB2[ ]; } public class A3 { private List lesB3 = new ArrayList(); }
package Bibliotheque; import Catalogue; public class Bibliotheque { private Catalogue leCatalogue; ... }
public class Emploi { private String titre private Double salaire; private Employe salarie; private Societe employeur; ... }
|
|
Les lignes de vie représentent des objets et non des classes |
loop (boucle)
alt (alternative)
opt (optionel)
par (parallèle)
region (région critique - un seul thread à la fois)
Bien que non présent dans UML, il est courant de trouver un diagramme de séquence particulier, le diagramme de séquence système ou DSS, où on ne représente qu’un seul objet : le système en cours de développement lui-même.
La décomposition hiérarchique permet de réaliser une description "TOP-DOWN" du système à réaliser.
On fait un Diagramme de Séquence Système pour chaque UC (issu du Diagramme d’UC) pour déterminer les échanges d’informations entre l’acteur et le système.
Ensuite on fait un Diagramme de Séquence (DS) pour décrire comment les objets composants le système (issus du Diagramme de Classes) collaborent pour réaliser le traitement demandé.
Le paradigme Modèle-Vue-Contrôleur, ou MVC (de l’anglais Model-View-Controller) est une architecture logicielle qui divise l’application en trois éléments importants (cf. MVC ci-dessous) :
chargé de gérer les élements d’information (comme la base de donnée)
interfaces entre l’application et l’utilisateur
chargés de faire le lien entre vues et modèle.
L’avantage de ce patron d’architecture :
|
|
Le MVC est issu d’un modèle de programmation des applications interactives proposé par Xerox pour le langage Smalltalk-80, repris par SUN et recommandé pour la plateforme J2EE. |
La vue correspond à l’interface avec laquelle l’utilisateur interagit. Sa tâche est :
Ces différents événements sont envoyés au contrôleur.
Le contrôleur gère les événements pour mettre à jour la vue ou le modèle et les synchroniser.
Il reçoit tous les événements de l’utilisateur et enclenche les actions à effectuer.
|
|
Le modèle contient les données manipulées par l’application. |
|
|
Il y a en général un contrôleur par UC. |
|
|
Les 3 packages présentés ci-dessus (cf. MVC regrouperont respectivement |
Il s’agit des classes, issues des 3 paquetages MVC, qui "participent", dans un DS donné, à la réalisation d’un UC. On fait notamment apparaître les méthodes utilisées par le DS dans chaque classe.
En fonction des langages et des architectures, vous trouverez autant de schéma MVC différents que l’on peut en imaginer! Attention à vous adaptez.
Cette partie est traitée ici.
Les états informatiques doivent faire l’objet d’une analyse précise avant de procéder à leur programmation.
Dans ce but on utilise une grille d’imprimante (ou grille d’impression).
Cette grille est remplie à partir d’une maquette utilisateur (dessin rapide permettant de capter les besoins de l’utilisateur)
Le report de la maquette utilisateur sur une grille d’imprimante permet de réaliser une mise à l'échelle de l'état et de donner des instructions précises au programmeur.
Elles sont généralement utilisées dans les grands centres d’impression.
L’impression est réalisée ligne par ligne avec un format fixe sur du papier en continu (pliage accordéon) muni de bandes d’entraînements latérales appelées bandes Carol.
Caractères utilisés : très limités (26 lettres et 10 chiffres et qq caractères spéciaux) Vitesse : en lignes par minutes. Elle peut varier de 200 à 2000 lpm.
Ces imprimantes fonctionnent avec une colonne d’aiguilles (9, 12, 24 … aiguilles) permettant d’imprimer les caractères sous forme d’un ensemble de points. Les aiguilles sont placées dans une tête d’écriture se déplaçant latéralement devant le papier.
Caract. utilisés : formes et tailles variées ainsi que mise en relief (gras, souligné, italique).
Vitesse : en cps (Caractères Par Seconde). Elle varie de 60 à 400 cps.
Elles utilisent les mêmes principes que les imprimantes à aiguilles mais les aiguilles sont remplacées par une série de buses projetant un jet d’encre sur le papier : plus de silence et meilleure qualité d’impression.
Un rayon laser magnétise localement un tambour sur lequel est projetée une encre en poudre. L’encre est attirée par les régions magnétisées du tambour et se dépose sur le papier sur lequel elle est fixée par chauffage. Les imprimantes laser impriment directement une page complète.
Les caractères : tous
Vitesse : en ppm (Page Par Minute). 10 ppm environ
On appelle liasse une superposition de plusieurs feuilles de papier chimique (de 2 à 4) permettant d’imprimer simultanément plusieurs exemplaires d’un même état. Les liasses ne peuvent être utilisées qu’avec les imprimantes lignes ou matricielles (qui « frappent » le papier).
Certaines informations apparaissant sur les états peuvent être- pré- imprimées par un imprimeur (à partir d’une maquette qu’on lui aura fournie).
Caractéristiques du pré-imprimé :
Il faut distinguer deux types d’informations apparaissant sur un état, les informations fixes et les zones variables.
Elles correspondent aux différents titres et encadrements. Les informations pré-imprimées sont forcément des informations fixes (on les représentera en rouge sur la grille d’impression).
les zones alphanumériques : format COBOL X(n)
les zones numériques entières :format COBOL 9(n)
les zones décimales avec séparateur : 9(n)V,9(m)
Chaque caractère, fixe ou variable, occupera une case de la grille d’imprimante.
Utilisation d’étoiles, de i majuscules et de tirets :
Il faut prévoir l’impression de la date d'édition de l'état (en haut à gauche). Dans le cas de listes se poursuivant sur plusieurs pages on rajoutera systématiquement les informations suivantes :
Il faudra veiller à imposer des sauts de page (FF : Form Feed) à certains endroits.
Si une ligne de variable se répète de façon identique sur plusieurs lignes, on indiquera la répétition en plaçant sous chaque variable une colonne de points. Des répétitions de blocs de lignes seront représentées par des accolades.
De façon à ce que le programmeur puisse identifier correctement chaque variable, on procédera à leur numérotation de gauche à droite et de haut en bas sur la grille d’imprimante.
Le numéro sera porté au-dessus de chaque zone variable en utilisant une couleur différente de façon à ne pas les assimiler aux informations fixes.
Seules les variables de la première ligne seront numérotées si la ligne est répétitive.
Les numéros de variables seront reportés dans une légende qui sera placée sur la grille d’imprimante s’il y a de la place ou sur une feuille jointe. La légende portera les informations suivantes : numéro et nom de la variable, format d'édition COBOL.
Les grandes étapes :
Deux grandes écoles :
Deux acteurs importants :
|
|
Définis par la loi! (n° 85-704 du 12 juillet 1985)
Le maître de l’ouvrage est la personne morale, …, pour laquelle l’ouvrage est construit. Responsable principal de l’ouvrage, il remplit dans ce rôle une fonction d’intérêt général dont il ne peut se démettre. Il lui appartient, après s'être assuré de la faisabilité et de l’opportunité de l’opération envisagée, d’en déterminer la localisation, d’en définir le programme, d’en arrêter l’enveloppe financière prévisionnelle, d’en assurer le financement, de choisir le processus selon lequel l’ouvrage sera réalisé et de conclure, avec les maîtres d’oeuvre et entrepreneurs qu’il choisit, les contrats ayant pour objet les études et l’exécution des travaux. |
Il nous faut aborder les outils et démarches modernes de développement :
Nous allons aborder une étude de cas tirée du livre de Pascal Roques.
|
|
Pour un apperçu du livre, cf. http://www.editions-eyrolles.com/Chapitres/9782212110708/chap01.pdf. |
Il s’agit de développer un service de vente en ligne (http://jeBouquine.com).
Nous allons rapidement survoler la méthode Neptune. Développée en collaboration avec des académiques (dont l’IRIT et des industriels (dont Communication & System), cette méthode couvre aussi bien le business model (modèle orienté "économique" qui aborde aussi bien le produit que des notions comme les objectifs, les opportunités, les processus, etc.) que le génie logiciel (software engineering) qui nous intéresse ici.
|
|
La méthode Neptune tire ses racines du Unified Process (cf. [RUP]). Elle est compatible avec la méthode de Pierre-Alain Muller (cf. [Muller]). Elle est supportée par un outil eclipse. Pour plus d’information, voir http://neptune.irit.fr/. |
|
|
qui utilise le mieux la méthode Neptune. L’an dernier ce prix était de 1.500 €! |
Les grandes étapes de la démarche sont :
L’objectif de cette étape est de définir l’environnement du système et son utilisation.
Plusieurs activités concernent cette phase :
L’objectif de cette étape est de commencer à organiser les classes déjà identifiées dans l'étape précédente et d’obtenir une première vue logique du système.
Une seule activité concerne cette phase :
L’objectif de cette étape est de définir l’architecture du système.
Plusieurs activités concernent cette phase et se déroulent en parallèle :
L’objectif de cette étape est de développer pour chaque package une conception détaillée.
Plusieurs activités concernent cette phase :
L’objectif de cette étape est de concevoir l’architecture physique de l’application.
Plusieurs activités concernent cette phase :
L’intérêt de la méthode Neptune réside essentiellement sur le fait qu’elle insiste sur la phase de vérification des modèles. Très détaillée, cette activité dépasse le cadre de ce cours d’introduction.
|
|
Pour plus de détail, voir le livre en ligne http://neptune.irit.fr/images/files/NeptuneBook/407719ps.pdf. |
La démarche que nous utilisons au DUT est résumée par le diagramme ci-dessous.
Cette partie sera abordée en S4, mais comme certains PTut nécessitent des rudiments, abordons-là rapidement.
Reprendre ici les questions des chapitres (à organiser en fichiers!) et également le quizz.
Document généré par Jean-Michel Bruel via AsciiDoc (version 8.6.8) de Stuart Rackham.
La version présentation a été générée en utilisant W3C HTML Slidy © de Dave Raggett, amélioré par Jean-Michel Inglebert.
Pour l’instant ce document est libre d’utilisation et géré par la Licence Creative Commons.
licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.
Cette Frequently Asked Question a été construite par expérience, en regroupant les questions des étudiants durant mes différentes interventions.
Cette FAQ peut servir de base à la révision d’examens.
(Par exemple, un acteur "Personne intéressée par l’achat d’un portable" et un autre acteur "Acheteur")
Oui, c’est toujours permis puisque les acteurs sont des rôles et non des personnes bien identifiées. La question qui se pose est : est-ce judicieux? Dans certains diagrammes on pourra restreindre l’usage de telle ou telle partie de l’application à tel ou tel rôle. Donc dans l’exemple ça semble intéressant de différentier (l’acheteur pourrait être identifié avec un login et un num de carte bleue, la personne intéressée ne l'étant pas par exemple, etc.).
Quelques autres questions que je laisse à votre sagacité :
blabla …
Les références…
[HighsmithFowler2001] Jim Highsmith and Martin Fowler. The agile manifesto. Software Development Magazine, 9(8) :29–30, 2001.
[1030005] Kieran Conboy and Brian Fitzgerald. Toward a conceptual framework of agile methods : a study of agility in different disciplines. In WISER ’04 : Proceedings of the 2004 ACM workshop on Interdisciplinary software engineering research, pages 37–44, New York, NY, USA, 2004. ACM.
[Roques2007a] Les Cahiers du Programmeur, UML2, Pascal Roques 3ème Edition, Eyrolles, 2007.
[Roques2007b] UML 2 par la pratique, Pascal Roques 6ème Edition, Eyrolles, 2007.
[Blanc2006] UML pour les développeurs, Xavier Blanc, Eyrolles, 2006.
[Longepe2006] Le projet d’urbanisation du S.I., C. Longépé, 3ème édition, Dunod, 2006.
[Gillet2008] Management des SI, M. & P. Gillet, Dunod, 2008.
[Muller] Modélisation objet avec UML. Pierre-Alain Muller & Nathalie Gaetner, Eyrolles, 2003.
|
|
Ressources
Les définitions ci-dessous sont regroupées à titre indicatif. Les sources utilisées sont :
|
Don’t Repeat Yourself :
Interface Homme-Machine
Modèle Conceptuel des Flux
Modèle Conceptuel des Traitements
Maîtrise d’ouvrage (MOA) Maîtrise d’oeuvre (MOE)
Modèle Organisationnel des Flux
Modèle Organisationnel des Traitements
Object Management Group : L’organisme international chargé des principales normes liés à l’objet (CORBA, UML, etc.).
Programme Pédagogique National
Schéma d'Enchaînement des Fenêtres
Schéma d'Enchaînement des Pages
Système d'Information
Schéma de Navigation d'Interfaces
Système Organisationnel
System Modeling Language ™ : le langage de modélisation de systèmes maintenu par l’OMG.
Technology Readiness Level : système de mesure employé par des agences gouvernementales américaines et par de nombreuses compagnies (et agences) mondiales afin d'évaluer le niveau de maturité d’une technologie (cf. Wikipedia).
Universal Ressource Locator